Makes sense, but we may want to always build the plugin and run this test like we do for hook_add test because it looks like this test checks TS API functionality but not the plugin itself.

Well, this test fails if I build without --enable-example-plugins, so I think we probably should add this skip.

Well, this test fails if I build without --enable-example-plugins

I understand it. So the change makes sense in that sense

, so I think we probably should add this skip.

If we just want to avoid autest test failure, yes.

I'm saying we should always build the plugin (or a copy of the plugin) to see if TS API works even if ATS is built without --enable-example-plugins.

Well, this test fails if I build without --enable-example-plugins

I understand it. So the change makes sense in that sense

, so I think we probably should add this skip.

If we just want to avoid autest test failure, yes.

I'm saying we should always build the plugin (or a copy of the plugin) to see if TS API works even if ATS is built without --enable-example-plugins.

Gotcha, then maybe we should put a copy of the request_buffer.c in the tests/tools/plugins/ folder so it gets built when we run the test.

I understand @maskit 's comment, but I wouldn't want the stop testing the example plugin either. I suppose ideally we would keep the example plugin test as is and add a second test that tests the API. But adding a direct copy doesn't seem to add too much value. Since our CI jobs build and run autests with --enable-example-plugins I think we're fine just adding the skip for now, personally speaking.

Ok, then adding the skip is progress for the ideal state in terms of code, although we'll lost a guarantee that the API is tested (someone might remove --enable-example-plugins from CI build in the future).

I'll find some time to make a new test to testing that API.